本章目標

本章替一個販售常溫手作食品的台灣微型品牌建立電商 MVP。完成後，顧客能在手機瀏覽商品、選規格、加入購物車並建立訂單；店家能管理商品、庫存與訂單。

第一版先用模擬付款，專注完成三個容易被低估的核心：後端重新計價、庫存不超賣、訂單保存成交快照。第 27 章才串接綠界付款、超商物流並說清楚電子發票邊界。

為什麼這一章重要

AI 很容易做出漂亮的商品卡與購物車，但真正的電商風險藏在畫面後面：使用者修改前端價格、兩個人買走最後一件、商品改價後歷史訂單跟著變動、訂單成立卻沒有保留庫存。

本章的成功標準：

• 前端送來的單價不被信任。
• 同一商品規格不會賣出超過庫存的數量。
• 訂單保存成立當下的名稱、規格、單價與數量。
• 重新整理或重複點擊不會建立兩張有效訂單。
• 管理者能追蹤每一次庫存增加與扣除。

思考模型：購物車是意圖，訂單才是承諾

購物車內容可能過期，也可能和最新商品資料不同。結帳時後端必須重新檢查：

購物車 -> 後端重新計價 -> 檢查庫存
       -> 建立訂單快照 -> 保留庫存 -> 待付款

因此不要直接把 cart items 複製成可信任訂單，也不要只保存 product ID。若商品隔天改名或改價，昨天的訂單仍必須呈現成交當下內容。

開始之前

準備 Lovable Cloud 或 Supabase。介面為繁體中文、金額使用新台幣整數、時區採 Asia/Taipei。本章不使用真實付款資料。

我要建立台灣常溫手作食品品牌的小型電商 MVP，請先規劃不要實作。
需要商品、規格、購物車、後端重新計價、庫存保留、結帳資料、訂單快照與管理後台。
前端不可決定單價或總額；兩個人競爭最後一件時只能一人成功；重複送出不可建立兩張有效訂單。
金額使用新台幣整數，地址與手機使用台灣格式。
第一版不要加入真實金流、物流、電子發票、促銷引擎、多倉或多幣別。
請提出資料模型、庫存狀態、權限、交易邊界、建置順序與驗收矩陣。

步驟 1：建立商品與規格

核心資料：

• products：名稱、slug、說明、發布狀態、圖片。
• variants：商品、SKU、規格名稱、price_twd、是否可售。
• inventory_levels：variant、現有量、保留量。
• inventory_movements：variant、類型、數量、關聯訂單、操作者、時間。

庫存可售量是 on_hand - reserved。不要只有一個可直接覆寫的 stock 欄位；盤點、保留、釋放與出貨都應留下 movement。

商品圖片需要替代文字與合理尺寸。食品案例可顯示成分與保存方式，但不宣稱未經確認的療效。

步驟 2：建立手機購物流程

商品列表先顯示名稱、起始價格、庫存狀態與清楚的規格入口。商品頁選擇 variant 和數量後才能加入購物車；停售或缺貨規格不可加入。

購物車前端可以即時計算預估金額，但要標示結帳時會重新確認。使用者返回商品頁或重新開啟網站時，購物車要能恢復。

圖 26-1：商品規格各自顯示 SKU、價格與庫存；最後一組有警示，缺貨規格不可加入。

請建立手機優先的商品列表、商品頁與購物車。
商品有多個 variant，每個 variant 使用新台幣整數價格與獨立庫存。
缺貨或停售規格不可加入，數量不可超過目前顯示的可售量。
購物車金額只能作為預估；畫面與程式都不要把前端價格當成訂單真相。
完成後測試 390px 手機與桌面版的選規格、改數量、刪除與返回流程。

圖 26-2：購物車顯示兩個規格與預估總額，同時提醒結帳會依後端價格和實際庫存重算。

步驟 3：收集最少結帳資料

本章支援宅配模擬，因此收姓名、台灣手機、Email、郵遞區號、縣市、行政區、地址。欄位有可見標籤與錯誤說明，手機正規化後儲存。

地址是個資，只能由訂單擁有者與必要工作人員查看。不要把地址放進分析事件、公開錯誤或一般應用日誌。

圖 26-3：示範只收姓名、台灣手機、Email 與取貨方式，並顯示冪等與後端重算提示。正式宅配版本再依配送需要收取最少地址欄位。

步驟 4：後端重新計價並建立快照

建立 create_order 後端操作：

1. 驗證 cart ownership 或訪客 checkout token。
2. 從資料庫重新讀取每個 variant 的可售狀態與單價。
3. 驗證數量與庫存。
4. 計算小計、運費與總額。
5. 建立 orders 與 order_items 快照。
6. 原子化增加 reserved quantity。
7. 回傳訂單編號與後端計算總額。

order_items 至少保存 product_name、variant_name、sku、unit_price_twd、quantity、line_total_twd。不要在顯示歷史訂單時重新 join 當前商品價格。

請實作 create_order 後端操作。
輸入只接受 cart ID、收件資料與 idempotency key，不接受前端單價、小計或總額。
後端重新讀取 variants、檢查可售狀態與庫存，計算新台幣整數總額，建立 order_items 成交快照並在同一交易保留庫存。
相同 idempotency key 重送時回傳既有訂單。任一品項失敗時整筆不成立，也不保留部分庫存。

步驟 5：處理庫存保留與逾時

待付款訂單保留庫存 30 分鐘。背景工作尋找逾時訂單，將其改為 expired 並釋放 reserved quantity，寫入 movement。工作必須冪等，重跑不能釋放兩次。

訂單狀態先使用 pending_payment/paid/cancelled/expired；履約狀態留到下一章。取消已付款訂單不應直接回補，需配合退款和出貨狀態判斷。

步驟 6：建立訂單確認與查詢

成功頁顯示訂單編號、後端計算金額、品項、收件方式與付款狀態。訪客訂單使用高熵查詢 token 並在資料庫保存雜湊；會員只能查看自己的訂單。

重新整理成功頁只讀取既有訂單，不再次呼叫 create_order。使用者修改網址不能看到其他人的地址或訂單。

圖 26-4：訂單保存成交當下的品名、規格、SKU、單價與數量，總額由後端計算並保留庫存 30 分鐘。

步驟 7：建立商品、庫存與訂單後台

管理者可發布／停售商品、調整價格、建立盤點 movement。客服可查看訂單和必要聯絡資料，但不能改商品價格或使用者角色。每次人工庫存調整要輸入原因。

後台將問題分為待付款、即將逾時、已逾時、已取消。不要提供直接覆寫總額或庫存數字而不留事件的快捷操作。

圖 26-5：可售量由 on_hand - reserved 得出；reserve、release、sale 與 adjustment 都留下不可覆寫的 movement。

圖 26-6：後台分開顯示待付款、即將逾時、已逾時與取消訂單，且不提供修改後端總額的入口。

步驟 8：驗證價格與競爭條件

至少測試：

1. 修改瀏覽器中的單價，訂單仍採後端價格。
2. 兩人同時購買最後一件，只有一張訂單成功保留。
3. 相同 idempotency key 重送只產生一張訂單。
4. 多品項中一項缺貨，整張訂單失敗且不保留其他品項。
5. 商品成立後改價，歷史訂單快照不變。
6. 逾時釋放工作重跑不會重複增加庫存。
7. 停售商品不可直接透過 API 結帳。
8. 顧客無法查詢別人的訂單與地址。

請驗證小型電商 MVP。
測試竄改前端價格、最後一件並行購買、重複 idempotency key、多品項部分缺貨、成立後改價、逾時工作重跑、停售商品與跨帳號查詢。
逐項列出後端計算、訂單快照、inventory movements、畫面結果與權限證據。

實作練習

建立鳳梨酥與手工餅乾兩項商品，各有 6 入與 12 入規格。將其中一個 variant 設為庫存 1，讓兩位使用者同時結帳；再修改商品價格並檢查既有訂單。最後讓一張待付款訂單逾時，確認保留量只被釋放一次。

常見錯誤

• 信任前端總額： 所有訂單金額都由後端重算。
• 只保存 product ID： 歷史訂單會跟著商品改名改價。
• 先扣每一項再建單： 中途失敗會留下部分扣庫存，應使用單一交易。
• 逾時工作不可重跑： 背景工作必須冪等。
• 客服可以改任何資料： 產品、庫存與角色管理要有不同權限。

上線前檢查清單

• [ ] 金額均為新台幣整數並由後端計算。
• [ ] order items 保存成交快照。
• [ ] 最後一件並行測試通過。
• [ ] 建單有 idempotency key。
• [ ] 庫存保留、釋放與盤點均有 movement。
• [ ] 逾時工作重跑不會重複釋放。
• [ ] 停售與缺貨在後端被拒絕。
• [ ] 地址與聯絡資料受到資料層權限保護。
• [ ] 訪客查詢 token 不可猜測且保存雜湊。
• [ ] 手機結帳與錯誤恢復已驗證。

延伸閱讀

• Lovable Cloud
• Supabase Database
• Supabase Row Level Security
• Lovable security

名詞解釋與延伸提問

• SKU：用來辨識可銷售規格的庫存單位代碼。
• 訂單快照：保存成交當下的名稱、規格與價格，不依賴後續商品資料。
• 庫存保留：待付款期間暫時占用可售量。
• Idempotency key：識別同一次建單意圖，避免重送建立多張訂單。

你可以接著問 Lovable：「請依我的規格數量、運費與保留期限，產生後端計價和庫存競爭測試。」下一章會把這張可靠訂單接上綠界付款、超商物流與發票流程。

嗨！我是 Wolke，曾任 Google Developer Expert（GDE，2019–2023） 與 LINE API Expert。我熱衷於研究 AI Agent、n8n 自動化工作流及全端開發架構，致力於將 AI 技術轉化為實際的生產力工具。

如果你喜歡這篇文章，歡迎透過以下方式與我交流，獲取更多技術實戰內容：

📚 技術著作：《實用的 Gemini API 開發點子書》，帶你運用 Gemini App、Google AI Studio、Gemini CLI 與 Antigravity IDE，打造 AI Agent 與實用產品。

📝 技術部落格：歡迎追蹤我的 Medium，我會持續分享 Agentic Automation、架構設計與實際開發的踩坑心得。

🎤 技術講座：我持續受邀至技術社群及研討會，分享 AI Agent、自動化工作流、DevOps 與全端開發實戰。曾於 2026 年 6 月 26 日的 DevOpsDays Taipei 2026 主講「不再只是寫腳本！讓 AI 代理人成為你的 SRE 最佳夥伴」工作坊。

如果你的企業、社群或學校正在尋找相關主題講者，歡迎私訊與我聯繫、洽談講座合作！

🎁 免費送 Lovable 額度給讀者！

我每個月會開放 10 個名額，每人 50 點 Lovable 額度，讓大家實際動手打造自己的網站或 App。

參加方式：

1. 訂閱本系列文章
2. 分享任一篇系列文章
3. 私訊分享截圖及你的 Lovable 帳號 Email

確認後，我會邀請你加入 Lovable workspace 並設定 50 點額度。名額有限，送完為止！